Columbia Kermit/kermit.zip/newsgroups/misc.20000114-20000217/[e-mail] _Thu Jan 20 18:26:34 2000.msg

Internet Message Format | 2020-01-01 | 7KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA15105
    for <[e-mail]>; Thu, 20 Jan 2000 18:26:34 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA12298
    for [e-mail]; Thu, 20 Jan 2000 18:23:19 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Frank da Cruz)
Subject: Case Study #12: C-Kermit's Telnet Client
Date: 20 Jan 2000 23:23:13 GMT
Organization: Columbia University
Message-ID: <8685d1$c07$[e-mail]>
To: [e-mail]


These days it seems that blessings are always mixed.  Everything's a
tradeoff.  The evolution of the Telnet protocol is no exception.  Primarily
to accommodate modern demands for security, the original simple protocol set
forth in RFC854 (1983) is no longer sufficient.  C-Kermit 7.0 includes a
fully modern Telnet implementation, complete with tradeoffs.

On the plus side, the C-Kermit Telnet client can handle authentication
securely using any of several different authentication methods, and it can
also encrypt your session and it can verify the identity of the host you are
connecting to (more about this in future installments).

On the minus side, initial connection can take a bit longer than before
because there's more to negotiate, and because of the time taken by reverse
Domain Name Service (DNS) lookups, which client and/or server might
initiate.  Sometimes connections can take a LOT longer.  The most common
causes of long delays are:

 . The reverse DNS lookup done by the target host.  If the computer you
   are Telnetting from is not registered in DNS, the host might wait a
   minute or two before deciding it's not going to get an answer to its
   DNS lookup.  The same thing happens no matter what Telnet client you
   use.  The only remedy is to ensure your computer is registered in DNS.

 . The reverse DNS lookup done by C-Kermit itself.  As above but in the
   other direction.  C-Kermit's lookup not only checks the host's identity
   but identifies which host you have actually reached in case the address
   you gave was that of a host pool.  But if this service prevents you
   from making the connection at all, or makes the process intolerably
   slow, you can suppress it with SET TCP REVERSE-LOOKUP OFF; the tradeoff
   is that you might not know which host you actually reached.

 . The Telnet server is not replying to messages that require a reply.
   This tends to occur mainly with older Telnet servers, but also can
   happen with new ones that are improperly coded.  In this case, Kermit
   eventually times out after several minutes and tells you what went
   wrong so you can fix or work around the problem.  Or you can you can
   (at your own risk) include the new /NOWAIT switch in your TELNET or
   SET HOST command:

     C-Kermit> telnet /nowait oldmini.xyzcorp.com

   The risk is that client and server might have conflicting ideas about
   certain parameters are supposed to agree, which can result in fractured
   sessions (or worse if you are trying to make a secure connection; more
   about this in a future posting).

These hints should get you past any new difficulties you might have
experienced when upgrading to C-Kermit 7.0 from prior versions.  Of course
there is much more to tell.  C-Kermit's Telnet protocol intepreter has been
entirely redesigned and recoded to handle most modern options, and to give
you total and detailed control over negotiation policies and actions for
each option.  It also offers expanded debugging capabities for
troubleshooting.  The full story can be found in:

  ftp://kermit.columbia.edu/kermit/f/telnet.txt

Before leaving the topic of Telnet, let's recall some of the advantages
of C-Kermit over the regular System Telnet client on Unix, VMS, etc:

 . It is more configurable than System Telnet.
 . It can transfer files over the Telnet connection.
 . It can translate character sets.
 . It can be scripted.
 . It can also be used for other kinds of connections.

And so on.  Given the advantages, why not not use C-Kermit as your only
Telnet client?  One answer might be "because the command-line syntax is
different."  For example, maybe you have a Web browser whose "helper" for
Telnet links is hardwired to be System Telnet, with a command line like:

  telnet host [ port ]

No worries!  C-Kermit 7.0 has a new feature called "command line
personalities", one of which is "telnet".  Watch this (Unix example):

  $ whereis telnet
  /usr/bin/telnet
  $ cd /usr/bin
  $ mv telnet systemtelnet
  $ ln -s /usr/local/bin/kermit telnet

(The same effect is achieved if you leave System Telnet alone, but place
the telnet -> kermit link ahead of System Telnet in the PATH.)

Now C-Kermit *is* Telnet and it responds to the regular Telnet command line:

  telnet host [ port ]

as System Telnet would.  And, like System Telnet, if you invoke it this way,
it exits automatically when the connection is closed.  But unlike Telnet,
you can still use it to transfer files, execute scripts, and all the rest.
For more information about command-line personalities, see Section 9.1 of
ckermit2.txt.

Finally, a word about scripting Telnet connections.  If the Telnet server
supports the Telnet protocol feature that lets the client supply your user
ID automatically, you might find that a login: (Username:, etc) prompt is
not issued; the server goes straight to the Password prompt.  Alternatively,
(and even more confusingly) it might print the login or username prompt, but
then fill in your username for you and then print the Password prompt.  In
case your script was not expecting such behavior, you can prevent C-Kermit
from sending your user ID to the server by including the following command
in your script:

  set login userid

before the SET HOST command that makes the connection (you'll also need to
do this if your user ID on the target is not the same as your local one).
Then your old script should work as before.

You can also recode any Telnet script to adapt automatically to the presence
or absence of a login: (Username:) prompt using MINPUT rather than INPUT.
For a sample C-Kermit 7.0 Telnet "Kerbang script", see:

  ftp://kermit.columbia.edu/kermit/scripts/ckermit/autotelnet

in the C-Kermit scripts library.

- Frank